The guard and regression test look focused. One adjacent case worth considering is whether the other pub/sub reply handlers can receive a non-empty but too-short array, for example an array with only the command string and no channel/count fields. If the parser accepts malformed RESP arrays from a server/proxy, a small table of malformed PSUBSCRIBE/PUNSUBSCRIBE/PMESSAGE replies would make this class of defensive parsing harder to regress.

Good point. Two parts to it:

1. The sibling paths were already safe against the too-short case. OnSubscribeImpl returns on reply_array.size() != 3 before touching element 0, and inside OnPsubscribeReply each branch only reads the channel/count fields when the size matches (3 for PSUBSCRIBE/PUNSUBSCRIBE, 4 for PMESSAGE). The only real gap was the unconditional reply_array[0] read at the top, which the empty-array guard now covers.

2. Added the table anyway so this stays pinned. Sentinel.OnPsubscribeReplyTooShortArray feeds command-only and partial PSUBSCRIBE/PUNSUBSCRIBE/PMESSAGE replies and checks no callback fires and nothing indexes past the end. Both tests pass under the addr;ub sanitizer build.